Detection of end-to-end transport quality

ABSTRACT

In various embodiments, methods and systems are disclosed for the real time detection of network conditions in conjunction with a remote presentation protocol. The link quality may represent the quality of the end-to-end connection between client and server with upper and lower bounds on the injection of additional traffic used for measurement. In some embodiments, the measurement technique may be selected based on the type of measurement that is desired. Accuracy may be maintained by selecting the type of measurement used based on current and previous network conditions. In one embodiment, a state model is used to determine the frequency of measurement and to determine when the measurements have produced a stable estimate of the link quality.

BACKGROUND

Remote computing systems can enable users to remotely access hostedresources. Servers on the remote computing systems can execute programsand transmit signals indicative of a user interface to clients that canconnect by sending signals over a network conforming to a communicationprotocol such as the TCP/IP protocol. Each connecting client may beprovided a remote presentation session, i.e., an execution environmentthat includes a set of resources. Each client can transmit signalsindicative of user input to the server and the server can apply the userinput to the appropriate session. The clients may use remotepresentation protocols such as the Remote Desktop Protocol (RDP) toconnect to a server resource. Protocols such as RDP typically handlegraphics, device traffic such as USB, printer keyboard and mouse and inaddition, virtual channels for application between server and a client.The terminal server hosts client sessions which can be in hundreds in atypical server configuration.

In a remote/virtual desktop environment, the amount of remotepresentation data being transmitted can vary during the course of aremote user session. Such a remote session may be established over anetwork link and the type of data exchanged with the remote user devicemay include graphics, audio and other types of data. the link qualitybetween client and server may vary in bandwidth, latency and/or loss.Remote presentation protocols typically rely on fixed/static sizedbuffers for networking traffic and if these are incorrectly sized theylead to either insufficient network usage or excess queuing in thenetwork, both of which negatively affect user experience.

SUMMARY

In various embodiments, methods and systems are disclosed for theaccurate, bounded, real time detection of current network conditionswhile working in conjunction with a remote presentation protocol such asRDP. The link quality may be reliably determined in real-time or nearreal-time so that the system may make adjustments as need. The linkquality may represent the quality of the end-to-end connection betweenclient and server with upper and lower bounds on the injection ofadditional traffic used for measurement. In some embodiments, themeasurement technique may be selected based on the type of measurementthat is desired. Accuracy may be maintained by intelligently selectingthe type of measurement used based on current and previous networkconditions. In one embodiment, a state model is used to determine thefrequency of measurement and to determine when the measurements haveproduced a stable estimate of the link quality.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 depict an example computer system wherein aspects of thepresent disclosure can be implemented.

FIG. 3 depicts an operational environment for practicing aspects of thepresent disclosure.

FIG. 4 depicts an operational environment for practicing aspects of thepresent disclosure.

FIG. 5 illustrates a computer system including circuitry foreffectuating remote desktop services.

FIG. 6 illustrates a computer system including circuitry foreffectuating remote services.

FIG. 7 illustrates examples of bandwidth and latency for variouscommunications methods.

FIGS. 8-19 illustrate an overview of some of the processes disclosedherein.

FIG. 20 illustrates an operational procedure incorporating aspects ofthe methods disclosed herein.

FIG. 21 illustrates an example system for incorporating aspects of thepresent disclosure.

FIG. 22 illustrates an operational procedure incorporating aspects ofthe methods disclosed herein.

DETAILED DESCRIPTION

Computing Environments In General Terms

Certain specific details are set forth in the following description andfigures to provide a thorough understanding of various embodiments ofthe disclosure. Certain well-known details often associated withcomputing and software technology are not set forth in the followingdisclosure to avoid unnecessarily obscuring the various embodiments ofthe disclosure. Further, those of ordinary skill in the relevant artwill understand that they can practice other embodiments of thedisclosure without one or more of the details described below. Finally,while various methods are described with reference to steps andsequences in the following disclosure, the description as such is forproviding a clear implementation of embodiments of the disclosure, andthe steps and sequences of steps should not be taken as required topractice this disclosure.

Embodiments may execute on one or more computers. FIGS. 1 and 2 and thefollowing discussion are intended to provide a brief general descriptionof a suitable computing environment in which the disclosure may beimplemented. One skilled in the art can appreciate that computer systems200, 300 can have some or all of the components described with respectto computer 100 of FIGS. 1 and 2.

The term circuitry used throughout the disclosure can include hardwarecomponents such as hardware interrupt controllers, hard drives, networkadaptors, graphics processors, hardware based video/audio codecs, andthe firmware/software used to operate such hardware. The term circuitrycan also include microprocessors configured to perform function(s) byfirmware or by switches set in a certain way or one or more logicalprocessors, e.g., one or more cores of a multi-core general processingunit. The logical processor(s) in this example can be configured bysoftware instructions embodying logic operable to perform function(s)that are loaded from memory, e.g., RAM, ROM, firmware, and/or virtualmemory. In example embodiments where circuitry includes a combination ofhardware and software an implementer may write source code embodyinglogic that is subsequently compiled into machine readable code that canbe executed by a logical processor. Since one skilled in the art canappreciate that the state of the art has evolved to a point where thereis little difference between hardware, software, or a combination ofhardware/software, the selection of hardware versus software toeffectuate functions is merely a design choice. Thus, since one of skillin the art can appreciate that a software process can be transformedinto an equivalent hardware structure, and a hardware structure canitself be transformed into an equivalent software process, the selectionof a hardware implementation versus a software implementation is trivialand left to an implementer.

FIG. 1 depicts an example of a computing system which is configured towith aspects of the disclosure. The computing system can include acomputer 20 or the like, including a processing unit 21, a system memory22, and a system bus 23 that couples various system components includingthe system memory to the processing unit 21. The system bus 23 may beany of several types of bus structures including a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. The system memory includes read only memory (ROM) 24and random access memory (RAM) 25. A basic input/output system 26(BIOS), containing the basic routines that help to transfer informationbetween elements within the computer 20, such as during start up, isstored in ROM 24. The computer 20 may further include a hard disk drive27 for reading from and writing to a hard disk, not shown, a magneticdisk drive 28 for reading from or writing to a removable magnetic disk29, and an optical disk drive 30 for reading from or writing to aremovable optical disk 31 such as a CD ROM or other optical media. Insome example embodiments, computer executable instructions embodyingaspects of the disclosure may be stored in ROM 24, hard disk (notshown), RAM 25, removable magnetic disk 29, optical disk 31, and/or acache of processing unit 21. The hard disk drive 27, magnetic disk drive28, and optical disk drive 30 are connected to the system bus 23 by ahard disk drive interface 32, a magnetic disk drive interface 33, and anoptical drive interface 34, respectively. The drives and theirassociated computer readable media provide non volatile storage ofcomputer readable instructions, data structures, program modules andother data for the computer 20. Although the environment describedherein employs a hard disk, a removable magnetic disk 29 and a removableoptical disk 31, it should be appreciated by those skilled in the artthat other types of computer readable media which can store data that isaccessible by a computer, such as magnetic cassettes, flash memorycards, digital video disks, Bernoulli cartridges, random access memories(RAMs), read only memories (ROMs) and the like may also be used in theoperating environment.

A number of program modules may be stored on the hard disk, magneticdisk 29, optical disk 31, ROM 24 or RAM 25, including an operatingsystem 35, one or more application programs 36, other program modules 37and program data 38. A user may enter commands and information into thecomputer 20 through input devices such as a keyboard 40 and pointingdevice 42. Other input devices (not shown) may include a microphone,joystick, game pad, satellite disk, scanner or the like. These and otherinput devices are often connected to the processing unit 21 through aserial port interface 46 that is coupled to the system bus, but may beconnected by other interfaces, such as a parallel port, game port oruniversal serial bus (USB). A display 47 or other type of display devicecan also be connected to the system bus 23 via an interface, such as avideo adapter 48. In addition to the display 47, computers typicallyinclude other peripheral output devices (not shown), such as speakersand printers. The system of FIG. 1 also includes a host adapter 55,Small Computer System Interface (SCSI) bus 56, and an external storagedevice 62 connected to the SCSI bus 56.

The computer 20 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer49. The remote computer 49 may be another computer, a server, a router,a network PC, a peer device or other common network node, a virtualmachine, and typically can include many or all of the elements describedabove relative to the computer 20, although only a memory storage device50 has been illustrated in FIG. 1. The logical connections depicted inFIG. 1 can include a local area network (LAN) 51 and a wide area network(WAN) 52. Such networking environments are commonplace in offices,enterprise wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 20 can beconnected to the LAN 51 through a network interface or adapter 53. Whenused in a WAN networking environment, the computer 20 can typicallyinclude a modem 54 or other means for establishing communications overthe wide area network 52, such as the Internet. The modem 54, which maybe internal or external, can be connected to the system bus 23 via theserial port interface 46. In a networked environment, program modulesdepicted relative to the computer 20, or portions thereof, may be storedin the remote memory storage device. It will be appreciated that thenetwork connections shown are examples and other means of establishing acommunications link between the computers may be used. Moreover, whileit is envisioned that numerous embodiments of the disclosure areparticularly well-suited for computer systems, nothing in this documentis intended to limit the disclosure to such embodiments.

Referring now to FIG. 2, another embodiment of an exemplary computingsystem 100 is depicted. Computer system 100 can include a logicalprocessor 102, e.g., an execution core. While one logical processor 102is illustrated, in other embodiments computer system 100 may havemultiple logical processors, e.g., multiple execution cores perprocessor substrate and/or multiple processor substrates that could eachhave multiple execution cores. As shown by the figure, various computerreadable storage media 110 can be interconnected by one or more systembusses which couples various system components to the logical processor102. The system buses may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. In exampleembodiments the computer readable storage media 110 can include forexample, random access memory (RAM) 104, storage device 106, e.g.,electromechanical hard drive, solid state hard drive, etc., firmware108, e.g., FLASH RAM or ROM, and removable storage devices 118 such as,for example, CD-ROMs, floppy disks, DVDs, FLASH drives, external storagedevices, etc. It should be appreciated by those skilled in the art thatother types of computer readable storage media can be used such asmagnetic cassettes, flash memory cards, digital video disks, andBernoulli cartridges.

The computer readable storage media provide non-volatile storage ofprocessor executable instructions 122, data structures, program modulesand other data for the computer 100. A basic input/output system (BIOS)120, containing the basic routines that help to transfer informationbetween elements within the computer system 100, such as during startup, can be stored in firmware 108. A number of programs may be stored onfirmware 108, storage device 106, RAM 104, and/or removable storagedevices 118, and executed by logical processor 102 including anoperating system and/or application programs.

Commands and information may be received by computer 100 through inputdevices 116 which can include, but are not limited to, a keyboard andpointing device. Other input devices may include a microphone, joystick,game pad, scanner or the like. These and other input devices are oftenconnected to the logical processor 102 through a serial port interfacethat is coupled to the system bus, but may be connected by otherinterfaces, such as a parallel port, game port or universal serial bus(USB). A display or other type of display device can also be connectedto the system bus via an interface, such as a video adapter which can bepart of, or connected to, a graphics processor 112. In addition to thedisplay, computers typically include other peripheral output devices(not shown), such as speakers and printers. The exemplary system of FIG.1 can also include a host adapter, Small Computer System Interface(SCSI) bus, and an external storage device connected to the SCSI bus.

Computer system 100 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer.The remote computer may be another computer, a server, a router, anetwork PC, a peer device or other common network node, and typicallycan include many or all of the elements described above relative tocomputer system 100.

When used in a LAN or WAN networking environment, computer system 100can be connected to the LAN or WAN through a network interface card 114.The NIC 114, which may be internal or external, can be connected to thesystem bus. In a networked environment, program modules depictedrelative to the computer system 100, or portions thereof, may be storedin the remote memory storage device. It will be appreciated that thenetwork connections described here are exemplary and other means ofestablishing a communications link between the computers may be used.Moreover, while it is envisioned that numerous embodiments of thepresent disclosure are particularly well-suited for computerizedsystems, nothing in this document is intended to limit the disclosure tosuch embodiments.

A remote desktop system is a computer system that maintains applicationsthat can be remotely executed by client computer systems. Input isentered at a client computer system and transferred over a network(e.g., using protocols based on the International TelecommunicationsUnion (ITU) T.120 family of protocols such as Remote Desktop Protocol(RDP)) to an application on a terminal server. The application processesthe input as if the input were entered at the terminal server. Theapplication generates output in response to the received input and theoutput is transferred over the network to the client computer system.The client computer system presents the output data. Thus, input isreceived and output presented at the client computer system, whileprocessing actually occurs at the terminal server. A session can includea shell and a user interface such as a desktop, the subsystems thattrack mouse movement within the desktop, the subsystems that translate amouse click on an icon into commands that effectuate an instance of aprogram, etc. In another example embodiment the session can include anapplication. In this example while an application is rendered, a desktopenvironment may still be generated and hidden from the user. It shouldbe understood that the foregoing discussion is exemplary and that thepresently disclosed subject matter may be implemented in variousclient/server environments and not limited to a particular terminalservices product.

In most, if not all remote desktop environments, input data (entered ata client computer system) typically includes mouse and keyboard datarepresenting commands to an application and output data (generated by anapplication at the terminal server) typically includes video data fordisplay on a video output device. Many remote desktop environments alsoinclude functionality that extend to transfer other types of data.

Communications channels can be used to extend the RDP protocol byallowing plug-ins to transfer data over an RDP connection. Many suchextensions exist. Features such as printer redirection, clipboardredirection, port redirection, etc., use communications channeltechnology. Thus, in addition to input and output data, there may bemany communications channels that need to transfer data. Accordingly,there may be occasional requests to transfer output data and one or morechannel requests to transfer other data contending for available networkbandwidth.

Referring now to FIGS. 3 and 4, depicted are high level block diagramsof computer systems configured to effectuate virtual machines. As shownin the figures, computer system 100 can include elements described inFIGS. 1 and 2 and components operable to effectuate virtual machines.One such component is a hypervisor 202 that may also be referred to inthe art as a virtual machine monitor. The hypervisor 202 in the depictedembodiment can be configured to control and arbitrate access to thehardware of computer system 100. Broadly stated, the hypervisor 202 cangenerate execution environments called partitions such as childpartition 1 through child partition N (where N is an integer greaterthan or equal to 1). In embodiments a child partition can be consideredthe basic unit of isolation supported by the hypervisor 202, that is,each child partition can be mapped to a set of hardware resources, e.g.,memory, devices, logical processor cycles, etc., that is under controlof the hypervisor 202 and/or the parent partition and hypervisor 202 canisolate one partition from accessing another partition's resources. Inembodiments the hypervisor 202 can be a stand-alone software product, apart of an operating system, embedded within firmware of themotherboard, specialized integrated circuits, or a combination thereof.

In the above example, computer system 100 includes a parent partition204 that can also be thought of as domain 0 in the open sourcecommunity. Parent partition 204 can be configured to provide resourcesto guest operating systems executing in child partitions 1-N by usingvirtualization service providers 228 (VSPs) that are also known asback-end drivers in the open source community. In this examplearchitecture the parent partition 204 can gate access to the underlyinghardware. The VSPs 228 can be used to multiplex the interfaces to thehardware resources by way of virtualization service clients (VSCs) thatare also known as front-end drivers in the open source community. Eachchild partition can include one or more virtual processors such asvirtual processors 230 through 232 that guest operating systems 220through 222 can manage and schedule threads to execute thereon.Generally, the virtual processors 230 through 232 are executableinstructions and associated state information that provide arepresentation of a physical processor with a specific architecture. Forexample, one virtual machine may have a virtual processor havingcharacteristics of an Intel x86 processor, whereas another virtualprocessor may have the characteristics of a PowerPC processor. Thevirtual processors in this example can be mapped to logical processorsof the computer system such that the instructions that effectuate thevirtual processors will be backed by logical processors. Thus, in theseexample embodiments, multiple virtual processors can be simultaneouslyexecuting while, for example, another logical processor is executinghypervisor instructions. Generally speaking, and as illustrated by thefigures, the combination of virtual processors, various VSCs, and memoryin a partition can be considered a virtual machine such as virtualmachine 240 or 242.

Generally, guest operating systems 220 through 222 can include anyoperating system such as, for example, operating systems fromMicrosoft®, Apple®, the open source community, etc. The guest operatingsystems can include user/kernel modes of operation and can have kernelsthat can include schedulers, memory managers, etc. A kernel mode caninclude an execution mode in a logical processor that grants access toat least privileged processor instructions. Each guest operating system220 through 222 can have associated file systems that can haveapplications stored thereon such as terminal servers, e-commerceservers, email servers, etc., and the guest operating systemsthemselves. The guest operating systems 220-222 can schedule threads toexecute on the virtual processors 230-232 and instances of suchapplications can be effectuated.

Referring now to FIG. 4, illustrated is an alternative architecture thatcan be used to effectuate virtual machines. FIG. 4 depicts similarcomponents to those of FIG. 3, however in this example embodiment thehypervisor 202 can include the virtualization service providers 228 anddevice drivers 224, and parent partition 204 may contain configurationutilities 236. In this architecture, hypervisor 202 can perform the sameor similar functions as the hypervisor 202 of FIG. 2. The hypervisor 202of FIG. 4 can be a stand alone software product, a part of an operatingsystem, embedded within firmware of the motherboard or a portion ofhypervisor 202 can be effectuated by specialized integrated circuits. Inthis example parent partition 204 may have instructions that can be usedto configure hypervisor 202 however hardware access requests may behandled by hypervisor 202 instead of being passed to parent partition204.

Referring now to FIG. 5, computer 100 may include circuitry configuredto provide remote desktop services to connecting clients. In an exampleembodiment, the depicted operating system 400 may execute directly onthe hardware or a guest operating system 220 or 222 may be effectuatedby a virtual machine such as VM 216 or VM 218. The underlying hardware208, 210, 234, 212, and 214 is indicated in the illustrated type ofdashed lines to identify that the hardware can be virtualized.

Remote services can be provided to at least one client such as client401 (while one client is depicted remote services can be provided tomore clients.) The example client 401 can include a computer terminalthat is effectuated by hardware configured to direct user input to aremote server session and display user interface information generatedby the session. In another embodiment, client 401 can be effectuated bya computer that includes similar elements as those of computer 100 FIG.1 b. In this embodiment, client 401 can include circuitry configured toeffect operating systems and circuitry configured to emulate thefunctionality of terminals, e.g., a remote desktop client applicationthat can be executed by one or more logical processors 102. One skilledin the art can appreciate that the circuitry configured to effectuatethe operating system can also include circuitry configured to emulate aterminal.

Each connecting client can have a session (such as session 404) whichallows the client to access data and applications stored on computer100. Generally, applications and certain operating system components canbe loaded into a region of memory assigned to a session. Thus, incertain instances some OS components can be spawned N times (where Nrepresents the number of current sessions). These various OS componentscan request services from the operating system kernel 418 which can, forexample, manage memory; facilitate disk reads/writes; and configurethreads from each session to execute on the logical processor 102. Someexample subsystems that can be loaded into session space can include thesubsystems that generates desktop environments, the subsystems thattrack mouse movement within the desktop, the subsystems that translatemouse clicks on icons into commands that effectuate an instance of aprogram, etc. The processes that effectuate these services, e.g.,tracking mouse movement, are tagged with an identifier associated withthe session and are loaded into a region of memory that is allocated tothe session.

A session can be generated by a session manager 416, e.g., a process.For example, the session manager 416 can initialize and manage eachremote session by generating a session identifier for a session space;assigning memory to the session space; and generating system environmentvariables and instances of subsystem processes in memory assigned to thesession space. The session manager 416 can be invoked when a request fora remote desktop session is received by the operating system 400.

A connection request can first be handled by a transport stack 410,e.g., a remote desktop protocol (RDP) stack. The transport stack 410instructions can configure logical processor 102 to listen forconnection messages on a certain port and forward them to the sessionmanager 416. When sessions are generated the transport stack 410 caninstantiate a remote desktop protocol stack instance for each session.Stack instance 414 is an example stack instance that can be generatedfor session 404. Generally, each remote desktop protocol stack instancecan be configured to route output to an associated client and routeclient input to an environment subsystem 444 for the appropriate remotesession.

As shown by the figure, in an embodiment an application 448 (while oneis shown others can also execute) can execute and generate an array ofbits. The array can be processed by a graphics interface 446 which inturn can render bitmaps, e.g., arrays of pixel values, that can bestored in memory. As shown by the figure, a remote display subsystem 420can be instantiated which can capture rendering calls and send the callsover the network to client 401 via the stack instance 414 for thesession.

In addition to remoting graphics and audio, a plug and play redirector458 can also be instantiated in order to remote diverse devices such asprinters, mp3 players, client file systems, CD ROM drives, etc. The plugand play redirector 458 can receive information from a client sidecomponent which identifies the peripheral devices coupled to the client401. The plug and play redirector 458 can then configure the operatingsystem 400 to load redirecting device drivers for the peripheral devicesof the client 401. The redirecting device drivers can receive calls fromthe operating system 400 to access the peripherals and send the callsover the network to the client 401.

As discussed above, clients may use a protocol for providing remotepresentation services such as Remote Desktop Protocol (RDP) to connectto a resource using terminal services. When a remote desktop clientconnects to a terminal server via a terminal server gateway, the gatewaymay open a socket connection with the terminal server and redirectclient traffic on the remote presentation port or a port dedicated toremote access services. The gateway may also perform certain gatewayspecific exchanges with the client using a terminal server gatewayprotocol transmitted over HTTPS.

Turning to FIG. 6, depicted is a computer system 100 including circuitryfor effectuating remote services and for incorporating aspects of thepresent disclosure. As shown by the figure, in an embodiment a computersystem 100 can include components similar to those described in FIG. 2and FIG. 5, and can effectuate a remote presentation session. In anembodiment of the present disclosure a remote presentation session caninclude aspects of a console session, e.g., a session spawned for a userusing the computer system, and a remote session. Similar to thatdescribed above, the session manager 416 can initialize and manage theremote presentation session by enabling/disabling components in order toeffectuate a remote presentation session.

One set of components that can be loaded in a remote presentationsession are the console components that enable high fidelity remoting,namely, the components that take advantage of 3D graphics and 2Dgraphics rendered by 3D hardware.

3D/2D graphics rendered by 3D hardware can be accessed using a drivermodel that includes a user mode driver 522, an API 520, a graphicskernel 524, and a kernel mode driver 530. An application 448 (or anyother process such as a user interface that generates 3D graphics) cangenerate API constructs and send them to an application programminginterface 520 (API) such as Direct3D from Microsoft®. The API 520 inturn can communicate with a user mode driver 522 which can generatesprimitives, e.g., the fundamental geometric shapes used in computergraphics represented as vertices and constants which are used asbuilding blocks for other shapes, and stores them in buffers, e.g.,pages of memory. In one embodiment the application 448 can declare howit is going to use the buffer, e.g., what type of data it is going tostore in the buffer. An application, such as a videogame, may use adynamic buffer to store primitives for an avatar and a static buffer forstoring data that will not change often such as data that represents abuilding or a forest.

Continuing with the description of the driver model, the application canfill the buffers with primitives and issue execute commands. When theapplication issues an execute command the buffer can be appended to arun list by the kernel mode driver 530 and scheduled by the graphicskernel scheduler 528. Each graphics source, e.g., application or userinterface, can have a context and its own run list. The graphics kernel524 can be configured to schedule various contexts to execute on thegraphics processing unit 112. The GPU scheduler 528 can be executed bylogical processor 102 and the scheduler 528 can issue a command to thekernel mode driver 530 to render the contents of the buffer. The stackinstance 414 can be configured to receive the command and send thecontents of the buffer over the network to the client 401 where thebuffer can be processed by the GPU of the client.

Illustrated now is an example of the operation of a virtualized GPU asused in conjunction with an application that calls for remotepresentation services. Referring to FIG. 6, in an embodiment a virtualmachine session can be generated by a computer 100. For example, asession manager 416 can be executed by a logical processor 102 and aremote session that includes certain remote components can beinitialized. In this example the spawned session can include a kernel418, a graphics kernel 524, a user mode display driver 522, and a kernelmode display driver 530. The user mode driver 522 can generate graphicsprimitives that can be stored in memory. For example, the API 520 caninclude interfaces that can be exposed to processes such as a userinterface for the operating system 400 or an application 448. Theprocess can send high level API commands such as such as Point Lists,Line Lists, Line Strips, Triangle Lists, Triangle Strips, or TriangleFans, to the API 420. The API 520 can receive these commands andtranslate them into commands for the user mode driver 522 which can thengenerate vertices and store them in one or more buffers. The GPUscheduler 528 can run and determine to render the contents of thebuffer. In this example the command to the graphics processing unit 112of the server can be captured and the content of the buffer (primitives)can be sent to client 401 via network interface card 114. In anembodiment, an API can be exposed by the session manager 416 thatcomponents can interface with in order to determine whether a virtualGPU is available.

In an embodiment a virtual machine such as virtual machine 240 of FIG. 3or 4 can be instantiated and the virtual machine can serve as a platformfor execution for the operating system 400. Guest operating system 220can embody operating system 400 in this example. A virtual machine maybe instantiated when a connection request is received over the network.For example, the parent partition 204 may include an instance of thetransport stack 410 and may be configured to receive connectionrequests. The parent partition 204 may initialize a virtual machine inresponse to a connection request along with a guest operating systemincluding the capabilities to effectuate remote sessions. The connectionrequest can then be passed to the transport stack 410 of the guestoperating system 220. In this example each remote session may beinstantiated on an operating system that is executed by its own virtualmachine.

In one embodiment a virtual machine can be instantiated and a guestoperating system 220 embodying operating system 400 can be executed.Similar to that described above, a virtual machine may be instantiatedwhen a connection request is received over the network. Remote sessionsmay be generated by an operating system. The session manager 416 can beconfigured to determine that the request is for a session that supports3D graphics rendering and the session manager 416 can load a consolesession. In addition to loading the console session the session manager416 can load a stack instance 414′ for the session and configure systemto capture primitives generated by a user mode display driver 522.

The user mode driver 522 may generate graphics primitives that can becaptured and stored in buffers accessible to the transport stack 410. Akernel mode driver 530 can append the buffers to a run list for theapplication and a GPU scheduler 528 can run and determine when to issuerender commands for the buffers. When the scheduler 528 issues a rendercommand the command can be captured by, for example, the kernel modedriver 530 and sent to the client 401 via the stack instance 414′.

The GPU scheduler 528 may execute and determine to issue an instructionto render the content of the buffer. In this example the graphicsprimitives associated with the instruction to render can be sent toclient 401 via network interface card 114.

In an embodiment, at least one kernel mode process can be executed by atleast one logical processor 112 and the at least one logical processor112 can synchronize rendering vertices stored in different buffers. Forexample, a graphics processing scheduler 528, which can operatesimilarly to an operating system scheduler, can schedule GPU operations.The GPU scheduler 528 can merge separate buffers of vertices into thecorrect execution order such that the graphics processing unit of theclient 401 executes the commands in an order that allows them to berendered correctly.

One or more threads of a process such as a videogame may map multiplebuffers and each thread may issue a draw command. Identificationinformation for the vertices, e.g., information generated per buffer,per vertex, or per batch of vertices in a buffer, can be sent to the GPUscheduler 528. The information may be stored in a table along withidentification information associated with vertices from the same, orother processes and used to synchronize rendering of the variousbuffers.

An application such as a word processing program may execute anddeclare, for example, two buffers—one for storing vertices forgenerating 3D menus and the other one storing commands for generatingletters that will populate the menus. The application may map the bufferand; issue draw commands. The GPU scheduler 528 may determine the orderfor executing the two buffers such that the menus are rendered alongwith the letters in a way that it would be pleasing to look at. Forexample, other processes may issue draw commands at the same or asubstantially similar time and if the vertices were not synchronizedvertices from different threads of different processes could be renderedasynchronously on the client 401 thereby making the final imagedisplayed seem chaotic or jumbled.

A bulk compressor 450 can be used to compress the graphics primitivesprior to sending the stream of data to the client 401. In an embodimentthe bulk compressor 450 can be a user mode (not shown) or kernel modecomponent of the stack instance 414 and can be configured to look forsimilar patterns within the stream of data that is being sent to theclient 401. In this embodiment, since the bulk compressor 450 receives astream of vertices, instead of receiving multiple API constructs, frommultiple applications, the bulk compressor 450 has a larger data set ofvertices to sift through in order to find opportunities to compress.That is, since the vertices for a plurality of processes are beingremoted, instead of diverse API calls, there is a larger chance that thebulk compressor 450 will be able to find similar patterns in a givenstream.

In an embodiment, the graphics processing unit 112 may be configured touse virtual addressing instead of physical addresses for memory. Thus,the pages of memory used as buffers can be paged to system RAM or todisk from video memory. The stack instance 414′ can be configured toobtain the virtual addresses of the buffers and send the contents fromthe virtual addresses when a render command from the graphics kernel 528is captured.

An operating system 400 may be configured, e.g., various subsystems anddrivers can be loaded to capture primitives and send them to a remotecomputer such as client 401. Similar to that described above, a sessionmanager 416 can be executed by a logical processor 102 and a sessionthat includes certain remote components can be initialized. In thisexample the spawned session can include a kernel 418, a graphics kernel524, a user mode display driver 522, and a kernel mode display driver530.

A graphics kernel may schedule GPU operations. The GPU scheduler 528 canmerge separate buffers of vertices into the correct execution order suchthat the graphics processing unit of the client 401 executes thecommands in an order that allows them to be rendered correctly.

All of these variations for implementing the above mentioned partitionsare just exemplary implementations, and nothing herein should beinterpreted as limiting the disclosure to any particular virtualizationaspect.

Detection of Link Quality

In various methods and systems disclosed herein, improvements to thetransmission of remote presentation graphics data to a client computermay be implemented to provide a more timely and rich user experience.The embodiments disclosed herein for encoding and transmitting graphicsdata may be implemented using various combinations of hardware andsoftware processes. In some embodiments, functions may be executedentirely in hardware. In other embodiments, functions may be performedentirely in software. In yet further embodiments, functions may beimplemented using a combination of hardware and software processes. Suchprocesses may further be implemented using one or more CPUs and/or oneor more specialized processors such as a graphics processing unit (GPU)or other dedicated graphics rendering devices.

In remote desktop scenarios the graphics content of a user's desktoplocated on a host computer (e.g., the server) is typically streamed toanother computer (e.g., the client). The server and the client willexchange the desktop graphics data in a well defined protocol or format.Microsoft's™ Remote Desktop Protocol (RDP) is an example of such aprotocol. The RDP protocol is a stream oriented protocol that may use astream based transport such as the Transmission Control Protocol (TCP)for exchanging data with the client. Protocols such as the TCP protocoltypically exhibit high latency especially when the underlying transportis a wide area network (WAN) connection. If such a link is used for RDPtraffic, such latencies may result in a negative user experience becausethe desktop graphics data may be delivered to the client in a timedelayed fashion.

In a remote/virtual desktop environment, the amount of RDP data beingtransmitted can vary during the course of a remote user session. Such aremote session may be established over a network link and the type ofdata exchanged with the remote user device may include graphics, audioand other types of data. the link quality between client and server mayvary in bandwidth, latency and/or loss. Remote presentation protocolstypically rely on fixed/static sized buffers for networking traffic andif these are incorrectly sized they lead to either insufficient networkusage or excess queuing in the network, both of which negatively affectuser experience.

If the connection is a local area network within, for example, aworkspace infrastructure, then typically the bandwidth is predictableand sufficient. But in a wide area network, the connection may encompassa number of network devices and the bandwidth may be restricted atvarious points. For example, a number of modems and internet serviceproviders may be part of the communications link. Since the link qualityis constantly changing, it is difficult for even a knowledgeableend-user to predetermine what that quality is. The result is that theavailable bandwidth and latency is unpredictable and in some casesinsufficient to adequately support a remote user session. It would bedesirable in such cases to determine the quality of the link and, basedon the link qualities, the upper remote session layers can be informedand can adjust the type and amount of data being sent.

A communications link is typically characterized by latency andbandwidth. Such characteristics may be measured in a controlledenvironment, but this is typically not possible in an end-to-end sessionover a wide area network. In some cases a method known as “ping-pong”may be used to measure the round-trip time but such methods areintrusive and require traffic flow to be stopped. Furthermore, sinceremote presentation data traffic can be routed through variousprotocols, it is difficult to determine the link quality by readingexisting metrics. However, by knowing the link quality, a remotepresentation system may regulate the data flows and ensure a better userexperience.

In various embodiments methods and systems are disclosed for theaccurate, bounded, real time detection of current network conditionswhile working in conjunction with a remote presentation protocol such asRDP. The link quality may be reliably determined in real-time or nearreal-time so that the system may make adjustments as need. The linkquality may represent the quality of the end-to-end connection betweenclient and server with upper and lower bounds on the injection ofadditional traffic used for measurement. In some embodiments, themeasurement technique may be selected based on the type of measurementthat is desired. Accuracy may be maintained by intelligently selectingthe type of measurement used based on current and previous networkconditions. In one embodiment, a state model is used to determine thefrequency of measurement and to determine when the measurements haveproduced a stable estimate of the link quality.

In an embodiment, an integrated control state model may be used tomaintain upper and lower bounds on how often detection/measurement isperformed to improve accuracy while reducing unnecessary overhead. Thecontrol state model may appear as a network consumer that determineswhich measurements are to be injected into the networking stream andwhen the measurements are to be performed. The control state model mayallow for normal remoting traffic to act as the network measurementprobe. In one embodiment, an extensible measurement request-reply packetmay be added to a remote presentation protocol that allows for variousnetwork measurements using a plurality of methods. Measurement may betaken at the remote presentation protocol (application) layer to allowfor complete end-to-end measurements. In some embodiments, a chainingauto-detect mechanism can be implemented such that the results of twoseparate instances used for different remote presentation connectionscan be combined.

As mentioned previously, in many cases the remote presentationapplication does not have a reliable measure of the link quality. Someprotocols may provide for an indication from the user. However, the hintmay not be used by end-users and may be incorrectly set. Furthermore,such hints are static and do not reflect the dynamic underlying networkconditions.

In various systems and methods, disclosed are mechanisms for providingfor the measurement of remote presentation data traffic as the dataflows from the source (e.g., the server) to the consumer (e.g., theclient/end user). In one embodiment, the mechanism may comprise threecomponents:

-   -   (a) a networking layer; its timers, and a designated remote        protocol packet.    -   (b) a control algorithm based on a set of state models.    -   (c) calculation/estimate algorithms that perform the measurement        and historical value transformation to a current network        characteristics estimate.

In an embodiment, the networking layer may consist of functions at theserver and the client such that both perform timing on networking packetstreams when requested. The client and server may also flush(immediately send) pending data. Additionally, the remote presentationprotocol may be augmented with a measurement request and reply packetthat allows for sender and/or receiver side measurement of transmissiontimes.

The measurement method may include ping-pong, payload weightedping-pong, packet pairing and packet pairing with payload. Depending onthe current network conditions, some of the methods may be more accuratethan others. By providing for flexibility in selecting the measurementmethod, the total number of measurements may be reduced. Additionally,interfacing with the networking data stream may allow for the use ofalready pending remoting traffic to act as the measurement payload, thusallowing for increased accuracy of available network bandwidth.

The control algorithm may comprise a state model based on the currentstates of the bandwidth and latency estimates. In an embodiment, themeasurement states may start at an unstable state and migrate to eithera state or a not needed (or high) state depending on actual real timemeasurements. A progressive time and traffic based decay function mayreduce the stable state to the unstable state to allow for both upperand lower bound measurement rates. The control algorithm may use thesestates for latency and bandwidth estimation. The algorithm may use theestimates and pending remote traffic to determine which measurementpacket(s) to inject into the networking stream.

The calculation/estimation algorithms may take the latest measurementvalues and historical values for measurements and update the currentestimates for the latency and bandwidth. The estimator may also updatethe confidence or stability of each measurement state. The changes mayuse an integral approximation to update values using the form:new=old+(error*factor). In one embodiment the factor may be 1/10.

The end-to-end transport quality determination function thus monitorsthe end to end throughput of a communications channel and estimates boththe current average achievable bandwidth and latency as well as themaximum possible link bandwidth. Those skilled in the art will recognizethat such end to end measurement techniques are not limited to remotepresentation sessions and can be applied to any situation in which anend to end link quality assessment is desired, in particular in contextssuch as wide area networks in which the presence of intermediate networknodes introduce some unpredictability or uncertainty in the end to endlink quality. By determining the link quality, the run-time tuning of acommunication may be adjusted to provide the best performance given thecurrent network conditions.

Those skilled in the art will readily recognize that each particularcomponent of the end-to-end transport quality determination function maybe distributed and executed by the client and servers and othercomponents in the network. For example, the function may comprise threeadditional server components, one new server to client protocol dataunit (PDU), one client to server PDU, an additional field in the clientinformation PDU, and an additional component on the client.

The network PDU may be in the form of a Request Acknowledgement (ReqACK)PDU that is sent from the server to the client and echoed back by theclient. This allows the measurement of latency and bandwidth viamultiple commonly deployed methods that can involve timers at both theserver and the client. When used as a ping-pong echo packet, the ReqACKPDU can be used for Connect-Time Detection (CTD) of latency for use indeciding whether or not to utilize one or more graphics sources.

In one embodiment, the following changes may be implemented in theremote presentation protocol to enable continuous bandwidth detection: aserver to client PDU; a Reply Request PDU, a client to server PDU, andan ACK Response PDU. A field in the Client Information PDU may beincluded that indicates that the new PDU is supported. The may indicatesupport, and the server can be configured so that it will not generatethe new packets unless the client indicates support.

Network connections may be characterized on two dimensions: bandwidthand latency. Networks may be classified depending on both dimensions, asshown in FIG. 7. Network experience may be improved by setting the levelof network buffering based on an accurate measurement of latency andbandwidth. It is preferable to use both latency and bandwidth because,for example, using a latency only threshold as show in FIG. 7 does notallow for differentiation between high speed wireless and a wired LANconnection. For any cases which are not high bandwidth and low latencyfor which the remote presentation protocol has sufficient throughput,both latency and bandwidth should be measured to calculate the networklatency bandwidth product.

Latency measurement may be performed using two methods: an active and apassive method. The active method is similar to that of the commoninternet tool “ping.” In this method the small reply request packet isinjected into the stream of outgoing graphics data and the time for howlong it takes to be acknowledged by the client is measured as shown inFIG. 8. As shown in FIG. 8, the round trip time (RTT) divided in halfprovides an approximation of the one way network latency. Also shown areseveral overhead items in the system that effect the measurement such asTSdelay (the sum of the server (sender) injecting the packet into thenetwork and TAdelay1 as the sum of all processing delays at the client(receiver)).

In the passive measurement method, the request and reply transactionscan be timed explicitly between the server and the client.

Referring to FIG. 9, illustrated is an example of a method for measuringbandwidth on the sender side. This form of measurement may be viewed asa form the method wherein a set of packets are echoed back to thesender, i.e., only one side sends a payload and the other sends anacknowledgement. This method is used because:

-   -   (1) many broadband systems have slower uplink connections that        are prone to flooding;    -   (2) the payload would have to be handled by a terminal services        server;    -   (3) a measurement can be based on current server to client        traffic (graphic updates). Unless there is sufficient virtual        channel traffic (file sharing, printing, etc.) there is        typically not enough client-to-server payload to allow for an        accurate measurement.

In one embodiment the model used to estimate the available bandwidth maybe based on a modified Hockney model (non linear—non asymptoticprofile).

In an embodiment, the measurement method for bandwidth on the receiverside may be a modified packet pairing algorithm. In packet pairing twoconsecutive packets may be timed for their separation at the receiver.The algorithm may be used for detecting contention on a network, but hasthree major requirements: accurate injection of pairs of packets at thesender, high quality timers on the receiving end, and a long sequence ofmeasurements with complex filtering and fitting to produce a reasonablyaccurate measurement. By measuring larger packets rather than singlepacket dispersion, the requirements can be reduced while providing anaccurate measurement.

Depicted in FIG. 10 is one example of packet pairing (for networkcontention detection) and receiver side measurement combined. The ReplyRequest PDU may be used to support both methods using its flags field.In this method, packets are injected at the sender and timed at thereceiver. Bandwidth can be calculated without the need for accuratelatency values. If immediate acknowledging is enabled on the client,both a RTT latency calculation can be measured as well as a full payloadHockney measurement.

FIG. 11 depicts an example of bandwidth measurement without addingartificial (dummy) data to the data traffic. Here, there is sufficientdata flowing from the server to the client to allow for a payloadmeasurement as shown in the figure. The amount of data that needs tomeasured may vary by network conditions and characteristics, theaccuracy of the method used, location in the stack, and stability of anyregression function used.

As mentioned previously, one model that can be used for network modelingis the Hockney model which states that latency and bandwidth componentsare separate and that a network can be modeled on an asymptoticbandwidth profile (linear assumed value). Referring to FIG. 13, r_(inf)is the maximum rate of transfer at infinite data size and r/2 and n/2are the half maximum rate and datasize (n/2) needed for half maximumrate. These values are characteristics of the entire end-to-end systemand may effect how measurements can be accurately made. For example, aone shot measurement would need a n/2 payload and knowledge of what n/2was in advance. For many WAN systems such as high speed broadband, theratio of T_(latency) and T_(BW) can be close for typical remotepresentation packet sizes.

The figure indicates the relationship between Time and DataSize fordelivery of a payload of size ‘DataSize’. For example,Time=T _(Latency) +T _(BW).Thus the ratio of T_(latency) to T_(BW) affects the accuracy (orconfidence) of a measurement. In some embodiments and as shown in FIG.14, the slope is not constant and so a bandwidth for different datasizes can be used to model the network (i.e., the modified Hockneymodel) and can either assumed or determined over time.

As noted above, to control buffer management in remote presentationprotocols, it is preferable if a good estimate of both bandwidth andlatency is known or that is known that the bandwidth latency product isbelow or above a predetermined level and that no further tuning can beperformed.

In one embodiment, the control algorithm maintains an accurate estimateof bandwidth and latency without injecting unnecessary packet requestsinto the system. To maintain an accurate estimate, however, the systemmay request periodic measurements. Accordingly, two limits can beimplemented—minimum inject rate and maximum injection rate.

The control algorithm may use a set of rules based on the state of themeasurements. In an embodiment and as shown in FIG. 15, the measurementstate may consist of the current estimates of latency and bandwidth,their historical values, and the current injection rate and status. Tomaintain a minimum monitoring frequency, an aging factor may be usedwith the stability of the latency and bandwidth values to force aperiodic measurement.

As shown in FIG. 16, in one scenario the states for latency can bestable, unstable and not_required. The state transitions for latency maydepend on the stability of current versus previous measurements and theestimated network characteristics. If the network is a local high speedLAN, the latency value can switch into a not_required mode where it isno longer maintained frequently. If the bandwidth deteriorates to apoint where is becomes important to determine the latency, the latencystate can transition again to unstable to force additional measurements.

If recent measurements contain a variance beyond a predeterminedthreshold dependant on the class of the network, then the state of thelatency estimate may be switched from stable to unstable. At this pointthe injection state may be flagged to include active latencymeasurements. When the latency measurements exhibit a reduced variancethen the state may transition to stable. The stable state as discussedabove may comprise an aging factor which forces a periodic measurement.

As shown in FIG. 17, in one scenario the states for bandwidth can bestable, unstable, and high. The states for bandwidth may be similar tothe states for latency with the exception that “high” indicates that thebandwidth is very high and may not be accurately gauged having alreadyforced a receiver side measurement and the measurement exhibit a highvariance. Both stable and high states may comprises aging factors. Ahigh bandwidth state means in effect that the network bandwidth latencyproduct is so high that the default amount of network buffering willallow for adequate performance and user experience.

The aging factors for stable and high states may use a weighted value.The aging value may be incremented each time a stable result iscalculated and decremented each time an out of range value iscalculated. At each periodic time step the factor may be reduced whenthe state is stable, which forces a periodic measurement.

When stable results are calculated, the results may be accumulated viaan approximate integral system. In one embodiment, the results may beaccumulated using new=old+(error*factor). The factor value may betunable. In an embodiment the factor value may be 0.1 during a stablestate. FIG. 18 illustrates one example of this effect on a connectionwith changing bandwidth.

As shown in FIG. 19, the states for measurement injection may be latencyneeded, bandwidth needed, both needed, and sleeping. When latencymeasurements are needed the control model may signal to the stack that ameasurement is needed that can calculate the RTT. The control model maysimilarly may signal when a bandwidth is needed except that the controlmodel may request a server or client side measurement based on thecurrent values and network configuration expected (i.e., a high speedLAN may need a client side measurement while a slower link may need astandard Hockney server side measurement). Additionally, the variance ofthe latency and bandwidth as compared to their relative ratios may alsobe used to determine how/when to take measurements. For example, incases where latency varies greatly and the latency is a high ratiocompared to bandwidth, receiver side measurements may be requested(e.g., as in a LAN).

The sleeping state may indicate that both latency and bandwidth arestable and that no measurements are currently needed. When the controlalgorithm is frequently called, the algorithm may use this interactionto age the stability values of latency and bandwidth. When the latencyor bandwidth becomes unstable due to aging, the control algorithm mayforce a needed measurement state for both latency and bandwidth even ifone state is still stable.

The type of packet measurement packet request may depend on the statesof the latency and bandwidth estimates, current estimate values (whichdefine transport type), and traffic profile reported to the controlalgorithm by the scheduler.

FIG. 20 depicts an exemplary operational procedure for determining linkquality between a computing device and a client computing devicecommunicatively coupled over a wide area network using a networkprotocol including operations 2000, 2002, 2004, 2006, 2008, 2010, and2012. Referring to FIG. 20, operation 2000 begins the operationalprocedure and operation 2002 illustrates determining a type of linkquality measurement. Operation 2004 illustrates selecting one of aplurality of transmission measurement functions based on said type oflink quality measurement and previously determined link conditions.Operation 2006 illustrates augmenting network data traffic between thecomputing device and the client computing device with a measurementrequest packet, wherein the contents of the measurement request packetis determined based on the selected transmission measurement method.Operation 2008 illustrates receiving a measurement reply packet from theclient computing device. Operation 2010 illustrates determining a linktransmission time based on the measurement reply packet. Operation 2012illustrates determining a link quality based on the link transmissiontime.

FIG. 21 depicts an exemplary system for determining link quality betweena computing device and a client computing device communicatively coupledover a wide area network using a network protocol as described above.Referring to FIG. 21, system 2100 comprises a processor 2110 and memory2120. Memory 2120 further comprises computer instructions configured totransmit remote presentation graphics data to a client computer. Block2122 illustrates using a state machine to maintain upper and lowerbounds on a frequency of link transmission time, wherein the statemachine is based on current and past link bandwidth and latencyestimates. Block 2121 illustrates selecting a transmission measurementmethod based on a desired type of link quality measurement andpreviously determined link conditions. Block 2126 illustrates augmentingnetwork data traffic between the computing device and the clientcomputing device with a measurement request packet, wherein themeasurement request packet is determined based on the selectedtransmission measurement method. Block 2128 illustrates receiving ameasurement reply packet from the client computing device. Block 2130illustrates determining a link transmission time based on themeasurement reply packet. Block 2132 illustrates determining a linkquality based on the link transmission time.

FIG. 22 depicts another exemplary operational procedure for determininglink quality between a computing device and a client computing devicecommunicatively coupled over a wide area network using a remotepresentation protocol including operations 2200, 2202, 2204, 2206, 2208,and 2210. Referring to FIG. 22, operation 2200 begins the operationalprocedure and operation 2202 illustrates selecting a transmissionmeasurement method based on a desired type of link quality measurementand previously determined link conditions. Operation 2204 illustratesaugmenting network data traffic between the computing device and theclient computing device with a measurement request packet, wherein thecontents of the measurement request packet is determined based on theselected transmission measurement method. Operation 2206 illustratesreceiving a measurement reply packet from the client computing deviceand operation 2208 illustrates determining a link transmission timebased on the measurement reply packet. Operation 2210 illustratesdetermining a link quality based on the link transmission time.

The foregoing detailed description has set forth various embodiments ofthe systems and/or processes via examples and/or operational diagrams.Insofar as such block diagrams, and/or examples contain one or morefunctions and/or operations, it will be understood by those within theart that each function and/or operation within such block diagrams, orexamples can be implemented, individually and/or collectively, by a widerange of hardware, software, firmware, or virtually any combinationthereof.

It should be understood that the various techniques described herein maybe implemented in connection with hardware or software or, whereappropriate, with a combination of both. Thus, the methods and apparatusof the disclosure, or certain aspects or portions thereof, may take theform of program code (i.e., instructions) embodied in tangible media,such as floppy diskettes, CD-ROMs, hard drives, or any othermachine-readable storage medium wherein, when the program code is loadedinto and executed by a machine, such as a computer, the machine becomesan apparatus for practicing the disclosure. In the case of program codeexecution on programmable computers, the computing device generallyincludes a processor, a storage medium readable by the processor(including volatile and non-volatile memory and/or storage elements), atleast one input device, and at least one output device. One or moreprograms that may implement or utilize the processes described inconnection with the disclosure, e.g., through the use of an applicationprogramming interface (API), reusable controls, or the like. Suchprograms are preferably implemented in a high level procedural or objectoriented programming language to communicate with a computer system.However, the program(s) can be implemented in assembly or machinelanguage, if desired. In any case, the language may be a compiled orinterpreted language, and combined with hardware implementations.

While the invention has been particularly shown and described withreference to a preferred embodiment thereof, it will be understood bythose skilled in the art that various changes in form and detail may bemade without departing from the scope of the present invention as setforth in the following claims. Furthermore, although elements of theinvention may be described or claimed in the singular, the plural iscontemplated unless limitation to the singular is explicitly stated.

What is claimed:
 1. A method for determining link quality between acomputing device and a client computing device communicatively coupledover a communication network using a network protocol, the methodcomprising: determining, in real time, a type of link qualitymeasurement; selecting one of a plurality of transmission measurementfunctions, each of the transmission measurement functions implementing adifferent transmission measurement methodology, based on said type oflink quality measurement and determined link conditions; augmentingnetwork data traffic between the computing device and the clientcomputing device with a measurement request packet, wherein the contentsof the measurement request packet is determined based on the selectedtransmission measurement function; receiving a measurement reply packetfrom the client computing device; determining a link transmission timebased on the measurement reply packet; and determining, in real time, alink quality based on the link transmission time.
 2. The method of claim1, wherein the plurality of transmission measurement functions comprisesone of ping-pong, payload weighted ping-pong, packet pairing and packetpairing with payload.
 3. The method of claim 1, further comprisingadjusting a run-time tuning of a remote presentation session between theclient computing device and the computing device using the link quality.4. The method of claim 1, wherein the link quality comprises latency andbandwidth.
 5. The method of claim 1, wherein request and replytransactions between the server and the client are timed.
 6. The methodof claim 1, wherein a set of packets are echoed back to the computingdevice.
 7. The method of claim 1, wherein the plurality of transmissionmeasurement functions comprises packet pairing and receiver sidemeasurement and request packets are injected at the computing device andtiming is performed at the client computing device.
 8. The method ofclaim 1, wherein the link quality is determined using Hockney networkmodeling.
 9. The method of claim 1, further comprising using a statemachine to maintain upper and lower bounds on a frequency of linktransmission time, wherein the state machine is based on current andpast link bandwidth and latency estimates.
 10. A system configured todetermine a link quality between a computing device and a clientcomputing device communicatively coupled over a communication networkusing a network protocol, comprising: at least one processor; and atleast one memory communicatively coupled to said at least one processorwhen the system is operational, the memory having stored thereincomputer-executable instructions that, upon execution by the processor,cause: using a state machine to maintain upper and lower bounds on afrequency of link transmission time, wherein the state machine is basedon current and past link bandwidth and latency estimates; selecting, inreal time, a transmission measurement method based on a desired type oflink quality measurement and previously determined link conditions;augmenting network data traffic between the computing device and theclient computing device with a measurement request packet, wherein themeasurement request packet is determined based on the selectedtransmission measurement method; receiving a measurement reply packetfrom the client computing device; determining a link transmission timebased on the measurement reply packet; and determining, in real time, alink quality based on the link transmission time.
 11. The system ofclaim 10, wherein the state machine states start at an unstable stateand migrate to one of a Not Needed or High state as a function of themeasurements.
 12. The system of claim 10, further comprising aprogressive time and traffic based decay function that reduces thestable state to an unstable state.
 13. The system of claim 10, whereinchanges to the state use an integral approximation to update values of aform new=old+(error*factor).
 14. The system of claim 13 wherein thefactor is approximately 1/10.
 15. The system of claim 10 wherein whenthe network is a local high speed LAN the latency value is set to a notrequired mode.
 16. The system of claim 10 wherein when the measurementscontain a variance above a predetermined threshold dependent on theclass of the network, the state of the latency estimate is changed fromstable to unstable.
 17. A method for determining link quality between acomputing device and a client computing device communicatively coupledover a communication network using a remote presentation protocol, themethod comprising: selecting, in real time, a transmission measurementmethod, from a plurality of available transmission measurement methodseach implementing a different transmission measurement methodology,based on a desired type of link quality measurement and previouslydetermined link conditions; augmenting network data traffic between thecomputing device and the client computing device with a measurementrequest packet, wherein the measurement request packet is determinedbased on the selected transmission measurement method; receiving ameasurement reply packet from the client computing device; determining alink transmission time based on the measurement reply packet; anddetermining, in real time, a link quality based on the link transmissiontime.
 18. The method of claim 17, further comprising using a statemachine to maintain upper and lower bounds on a frequency of linktransmission time, wherein the state machine is based on current andpast link bandwidth and latency estimates.
 19. The method of claim 17,wherein the link quality comprises latency and bandwidth.
 20. The methodof claim 19, wherein the latency is determined by the round trip time(RTT).